Rustの信頼性へのアプローチは、バグを避けることだけにとどまらず、 意識的な設計の哲学です。すべての潜在的な失敗を、2つの領域に分類します： 回復可能な および 回復不可能な エラー。これにより、システムは耐障害性があり、予測可能で、静黙的なデータ破損から安全になります。
1. 失敗の分類
回復可能な エラー （例：ファイルが見つからない）は、プログラムが再試行したりユーザーに通知できる予期される障壁です。一方、 回復不可能なエラー （例：バッファオーバーフロー）は、論理的な破綻を示し、最も安全な対応は即座に停止することです— フェイル・ファスト 原則。
2. 契約ベースの開発
信頼性は明確な境界によって達成されます。関数の前提条件が満たされているにもかかわらず、外部要因によって失敗が生じた場合、 Resultを返す必要があります。内部ロジックがコアの不変量を違反した場合、Rustはシステム状態へのさらなる損害を防ぐために停止を強制します。
main.py
TERMINALbash — 80x24
> Ready. Click "Run" to execute.
>
QUESTION 1
Which of the following best describes a 'recoverable error' in Rust?
A total breakdown of logic where the program must halt.
An expected situation, such as a missing file, that the program can handle.
A memory leak that is automatically fixed by the compiler.
An error that only occurs in debug mode.
✅ Correct!
Correct! Recoverable errors are anticipated events where the code can take corrective action.❌ Incorrect
Think of errors like a 'File Not Found'—the program doesn't need to crash; it can just ask the user for a different file.QUESTION 2
What is the primary purpose of an 'unrecoverable error' (panic)?
To notify the user that their password was incorrect.
To stop execution immediately when a bug or contract violation is detected.
To provide a way for the program to retry a network request.
To optimize the code for better performance.
✅ Correct!
Exactly. Rust uses panics to 'Fail Fast' and prevent corrupted states from causing further harm.❌ Incorrect
Panics are for bugs and impossible states, not for routine user input issues.QUESTION 3
Why does Rust prefer explicit error handling over exceptions?
To make the code harder to read for security.
To prevent 'silent failures' that lead to corrupted states or vulnerabilities.
Because Rust does not have a stack to bubble up errors.
To allow the program to ignore errors completely.
✅ Correct!
Rust forces you to acknowledge potential failure points at design time, ensuring state integrity.❌ Incorrect
Exceptions often bubble up invisibly; Rust makes the possibility of failure a part of the function's type signature.QUESTION 4
If a function receives input that violates its core invariants (a bug), it should:
Return a Result::Err.
Panic to signal a logic error.
Ignore the input and return a default value.
Print a warning and continue.
✅ Correct!
Correct. If the program enters a state that should be impossible, halting is the safest path.❌ Incorrect
Return a Result for expected failures. If the logic itself is broken, that is a panic-worthy event.QUESTION 5
Which Rust type is used to represent a recoverable failure?
Option<T>
Result<T, E>
panic!
Box<dyn Error>
✅ Correct!
The Result enum explicitly encodes either success (Ok) or a handled failure (Err).❌ Incorrect
The panic! macro is for unrecoverable failures; Result is the container for recoverable ones.Case Study: The Resilient Web Server
Applying error philosophy to system design
You are designing a high-traffic web server. You must decide how to handle two distinct scenarios: 1) A user providing an invalid API key, and 2) The server detecting that its internal routing table has been corrupted by a memory-unsafe operation in a linked C-library.
Q
1. How should the 'Invalid API Key' scenario be handled and why?
Solution:
This should be a recoverable error returned via a
This should be a recoverable error returned via a
Result. It is an expected part of operation; the server should return a 401 status code and continue serving other requests.Q
2. How should the 'Corrupted Routing Table' scenario be handled and why?
Solution:
This must be an unrecoverable error triggering a
This must be an unrecoverable error triggering a
panic!. Since the internal state is corrupt, continuing to process transactions could lead to severe security leaks or data loss. Failing fast is the safest choice.